AWSアカウントとVPC、分ける？ 分けない？: 分割パターンのメリット・デメリット

こんにちは、虎塚です。

AWSを使っていて、次のような疑問を持たれたことはあるでしょうか。

• 「開発環境と本番環境ではVPCを分けたほうがいいかな？」
• 「新しく開発するシステムのためにAWSアカウントを新規に取得したほうがいいの？」

私はあります。また、クラスメソッドのお客さまにとっても、業種や組織の規模の違いを超えて、共通のお悩みであるようです。

この記事では、AWSアカウントとVPCの構成パターンと選択時の観点を整理してご紹介します。

AWSアカウントとVPCのよくある分割パターン

AWSアカウントとVPCの分割パターンを表にまとめます。よくある分割の基準として、システムの種類と環境の用途を取り上げました。

システムの種類とは、言葉のとおりですが、メインシステムとサブシステムのように連携するシステム (例: 会員システムと会員ポイント計算システム) 、相互に連携しないシステム (例: 店舗在庫システムと社内研修管理システム) の両方を含むものとします。

環境の用途とは、システムにアクセスする人がその環境をどう使うかを指します。たとえば、開発用、ステージング用、本番用などです。

No.	アカウント数	アカウント分割の軸	VPC数	VPC分割の軸
1-1	単一	N/A	単一	N/A
1-2			複数	システムの種類と環境の用途
1-3				システムの種類
1-4				環境の用途
2-1	複数	システムの種類	複数	環境の用途
2-2			（アカウント内で）単一	N/A
3-1		環境の用途	複数	システムの種類
3-2			（アカウント内で）単一	N/A
4		システムの種類と環境の用途	（必然的に）複数	N/A

分割の基準を2つに絞っても、9パターンもありました。各構成を1つずつ見ていきましょう。

1. 単一のAWSアカウントを使う

この構成パターンは、一見単純です。しかし、すべてのシステムを1つのAWSアカウントの中に構築するため、アカウント内の環境はかなり複雑になります。

1-1. 単一のAWSアカウント、単一のVPC

default VPC以外のVPCを1つ明示的に作り、その中に複数のシステム、複数の環境を混在させる構成です

1-2. システムの種類と環境の用途でVPCを分割

システムの種類でVPCを分け、さらに本番用と開発用など環境の用途によってもVPCを分ける構成です

1-3. システムの種類でVPCを分割

システムの種類によってVPCを分けますが、開発環境や本番環境を1つのVPC内に構築する構成です

1-4. 環境の用途でVPCを分割

環境の用途によってVPCを分けますが、複数の異なるシステムを1つのVPC内に構築する構成です

2. システムの種類でAWSアカウントを分割する

システムの種類ごとに別のAWSアカウントを用意するパターンです。AWS利用料はアカウントごとの請求となるので、システムの主管部署が異なる場合に、この構成はマッチします。

2-1. システムの種類でアカウントを分割し、環境の用途でVPCを分割

あるシステム用のアカウント内で、本番、ステージング、開発などの用途別にVPCを作成する構成です

2-2. システムの種類でアカウントを分割し、VPCはアカウント内で単一

あるシステム用のアカウント内で、1つのVPCに本番環境、ステージング環境、開発環境などを同居させる構成です

3. 環境の用途でAWSアカウントを分割する

2とは反対に、環境の用途ごとにAWSアカウントを用意するパターンです。

3-1. 環境の用途でアカウントを分割し、システムの種類でVPCを分割

用途別にアカウントを作成し、アカウント内でシステムの種類ごとにVPCを作成する構成です

3-2. システムの種類でアカウントを分割し、VPCはアカウント内で単一

用途別にアカウントを作成し、用途が共通する複数のシステムを1つのVPC内にまとめて構築する構成です

4. システムの種類と環境の用途でAWSアカウントを分けるパターン

AWSアカウントとVPCを最も細かく分割する構成です。システムAの開発環境用に1アカウント、システムAの本番環境用に1アカウント、システムBの開発環境用に1アカウント、といった具合に、AWSアカウントをどんどん作成します。

結論を先に書くと、お客様にクラスメソッドが通常おすすめするのは、こちらの構成です。

検討する際の観点

上で挙げた構成を、いくつかの観点に基づいてざっくり評価した表を次に示します。システムで重視したいポイントについて、★が多い構成を採用してください。

構成	コスト	セキュリティ	運用性	拡張性
1-1. 単一アカウント、単一VPCにすべて構築	★★★★★	★☆☆☆☆	★☆☆☆☆	★☆☆☆☆
1-2. 単一アカウントで、システムの種類と環境の用途でVPCを分割	★★★★☆	★★☆☆☆	★★★☆☆	★☆☆☆☆
1-3. 単一アカウントで、システムの種類でVPCを分割	★★★★☆	★★☆☆☆	★★☆☆☆	★☆☆☆☆
1-4. 単一アカウントで、環境の用途でVPCを分割	★★★★☆	★★☆☆☆	★★☆☆☆	★☆☆☆☆
2-1. システムの種類でアカウントを分割し、環境の用途でVPCを分割	★★★★☆	★★★☆☆	★★★☆☆	★★★☆☆
2-2. システムの種類でアカウントを分割し、VPCはアカウント内に単一	★★★★☆	★★★☆☆	★★☆☆☆	★★★☆☆
3-1. 環境の用途でアカウントを分割し、システムの種類でVPCを分割	★★★★☆	★★★☆☆	★★★☆☆	★★☆☆☆
3-2. 環境の用途でアカウントを分割し、VPCはアカウント内に単一	★★★★☆	★★★☆☆	★★☆☆☆	★★☆☆☆
4. システムの種類と環境の用途でアカウントを分割	★★★☆☆	★★★★★	★★★★★	★★★★★

AWSアカウントを分けるときと分けないとき、VPCを分けるときと分けないときで、具体的にどのような影響があるかを知りたい方は、続きをお読みください。

コスト

まず、AWSアカウントを分けることに、AWS利用費上のデメリットはありません。ご存じのとおり、AWSは実際に利用した量に対して課金され、最低月額のようなものはありませんので、アカウントを作成しただけでは費用は発生しません。

次に、VPCを新規に作ることにも、コスト面のデメリットはありません。VPC自体の作成・使用には料金がかからないためです。VPN接続を作成したり、NAT Gatewayを作成したり、データ転送が発生したりした場合に、料金がかかります。そのため、VPNやNAT Gatewayを利用する場合は、VPCごとに必要になるという意味で、VPCを分けることはデメリットです。

そして、Direct Connectを利用する場合、AWSのポート料金は物理回線ごとに課金のため、VPCを分割してもコストが増えることはありません（ただし、契約するベンダーによっては、共用タイプの回線プランで、VPCにattachするVIFごとに料金がかかる場合があります）。

最後に、RI (Reserved Instance) はAWSアカウント間で共有できないため、RIを使い切れずに余らせてしまった場合は、アカウントを分割することがデメリットになるかもしれません。ちなみに、Consolidated Billingを使うことで、アカウントファミリー内に未使用のRIがあると自動的にRIが割引になる仕組み (ブレンドレート) があります。

セキュリティ

アカウント管理

AWSアカウントが複数あることで、IAM UserやIAM Roleを発行する手間が増えるのはデメリットです。とはいえ、AWSにはロール切替えのような便利な仕組みがありますので、個人が複数のAWSアカウントを管理する手間は、それほど深刻ではないと思います。

リソースへのアクセス制御

システムによってアクセスを許可する利用者が厳密に定められている場合、AWSリソースへのアクセス権の設計や実装を注意深くおこなう必要があります。

AWSアカウントをシステムの種類や用途によって分けておくと、アクセス制御の設定がシンプルになるという大きなメリットがあります。複数のシステムを抱える組織では、システムの種類や環境の用途によって、利用者の所属組織が異なることがよくあります。たとえば、次のようなケースでは、AWSアカウントを分けることでアクセス制御を簡単に実現できます。

• 会計システムは、自社の開発者とA社の開発者が利用する。人事システムは、自社の開発者だけが利用する。
• 在庫管理システムの本番環境は、自社の特定の担当者だけが利用する。同システムの開発環境は、それに加えて、関連会社やビジネスパートナーも利用する。

単一のAWSアカウント内で上のようなケースに対処するには、利用者のIAM UserやIAM Roleに設定するIAMポリシーに、さまざな条件を記述しなければなりません。これは、役割が異なる複数のシステムを、1つのAWSアカウントやVPCにまとめることの大きなデメリットです。

Management Consoleでの閲覧範囲の問題

単一のAWSアカウントに複数のシステムを構築した場合のデメリットとして、AWS Management Console上ですべてのAWSリソースを一覧できてしまうことが挙げられます。Management Consoleでは、利用者の権限に応じて、AWSリソースの一部を表示したり非表示にしたりすることはできません。たとえば、S3のバケット一覧では、そのAWSアカウント内のすべてのバケットが見えてしまいます。EC2のインスタンス一覧も同じです。

このことにはセキュリティの観点で懸念がある上に、AWS Management Consoleで開発や運用の担当者が作業をおこなうときに、操作ミスや見間違いをする可能性が高くなる問題もあります。しかし、操作ミスを防ぐために必要なIAMポリシーの設定は、前述のとおりいろいろな条件の定義を必要とするために、どうしても複雑になります。

運用性

AWS利用費の可視性

AWSアカウントを分けると、システムや環境に発生したAWS利用費を、アカウントごとに区別して確認できます。AWS利用費は、AWSアカウントごとに請求されるためです。

複数のシステムや複数の環境が1つのAWSアカウントに混在していると、それぞれにいくらかかったかを確認できません。リソースにコスト配分タグ をつけることで、リソースごとに利用料を確認できるAWSサービスもありますが、現時点でタグに未対応のAWSサービスもあります。特に、データ転送料金に関してはアカウントで一括請求となるため、システムごとのデータ転送料金を確認するには、アカウントを分けるしかありません。

リソースのクロスアカウント共有可否に注意

AMI、EBSのスナップショット、RDSのスナップショットなどは、AWSアカウントをまたいで共有できます。しかし、ストレージ系やデータストア系のサービスをリアルタイムで参照したい場合は、VPCやアカウントを分割していると、VPCピアリングによって内部通信するなどの工夫が必要です。

オペレーション時の負荷

単一のAWSアカウントに複数のシステムがあると、リリース、パッチ適用、バックアップ、リカバリ、障害調査などの日々のオペレーションが、AWSアカウントを分割している場合とくらべると煩雑になります。操作対象でないシステムが、対象システムのすぐ隣にあるため、悪影響をおよぼさないように作業する必要があります。

場合によっては、意図しないAWSリソースを操作しないように、ガードのためのツールやサービスを併用する必要があるかもしれません。そんなことをするよりも、AWSアカウントを分けるほうが簡単です。

CloudTrailの閲覧性

CloudTrailは、AWSアカウント内でおこなわれたAPI操作のログを一括して記録します。AWSリソースの用途によって区別してログを出力することは、現時点ではできません。

単一のAWSアカウントに複数のシステムや複数の環境を構築すると、次のようなことが起こります。たとえば、システムAの本番環境に対して発行したAWS APIの実行ログを調べたいときに、同じアカウントに同居するシステムBやシステムC、さらにはシステムAの開発環境に対して発行したAPIログが混在したログファイルから、必要なログレコードを探しだす羽目になります。

システムの種類や環境の用途ごとにAWSアカウントを分割しておけば、APIログの活用のために本来不要なはずの手間をかけずに済みます。

拡張性

多くのAWSリソースには、作成できる上限の個数が定義されています。1つのアカウントに複数のシステムを構築した場合、有限のAWSリソースをさまざまなシステムで取り合うことになります。

一方、個人や組織が作成できるAWSアカウント数には制限がないため、最初からAWSアカウントを分割しておけば、システムの種類や環境の用途が増えても問題になりません。

一例として: ネットワークリソース

1-2, 1-3, 1-4のような単一アカウントの構成では、システムの種類と環境の用途が増えるたびに、アカウント内のVPCを新規に増やします。1つのAWSアカウントで1リージョンあたりに作成できるVPC数の上限は5個です。そのため、システムの種類や環境の用途が増えたら、サポートに連絡して上限緩和を申請する必要があります。

さらに、1つのAWSアカウントで利用できるElastic IPアドレスは、5個までです（上限緩和申請をすることで、この制限は緩和できます）。

また、利用できるIPアドレスの範囲も有限です。AWSの仕様で、VPCのサイズは/28〜/16と決められています。最大サイズのVPCを作った場合、65,536個 − 予約済みIPアドレス5個 = 65,531個のIPアドレスが利用できます。単一のAWSアカウントに複数のシステムを作ると、このIPアドレス範囲をシステムが取り合います。利用可能なIPアドレス範囲の設計、ひいてはサブネットの設計を慎重におこなう必要があります。

どの構成を選べばよいか

結局、「どんなシステムを作り、どのように使いたいか」次第ですが、迷うときは4のパターンを強くおすすめします。それでもお悩みの場合は、クラスメソッドのAWSチームにご相談ください。

AWSを利用するシステムが増えて、すでにある構成の変更を検討されている場合も、

• 現状の構成が記事の前半で紹介したどのパターンに当てはまるか
• 将来どんなふうにAWSを使っていきたいと考えているか

をお知らせいただくことで、ベターな構成選びをお手伝いできると思います。

おわりに

AWSでは柔軟な構成ができるぶん、選択肢がたくさんあります。かならずこうせぇという構成はありませんので、それぞれのメリットとデメリットを考えて選びましょう。

また、構成を変えたくなったら簡単に変えられるのも、AWSの素晴らしいところです。あまり心配せずに、まずは4の構成でスタートしまってもよいのではないでしょうか。

それでは、また。